Database systems provide processes for storing and retrieving information on persistent storage devices. Database objects are logical data structures that are used by a database server of a database system to store and organize both data in the database and procedures that operate on the data in the database. For example, in a relational database, a table is a database object with data arranged in rows, each row having one or more columns representing different fields. Another database object is a package of procedures that may be invoked and executed by the database server. In general, a database object includes one or more data items, each data item having values for one or more fields.
The stored information may belong to one or more entities, such as companies, associations and government organizations. In general, the entity that owns the stored information desires that access to the information be limited to particular users or groups of users. The entities often look to the database system to enforce access controls.
Many commercial database systems control access using a log-on procedure that determines authorized users. For example, a user who correctly enters a user identification (user ID) and a password is allowed access as an authorized user. One or more privileges are assigned to each authorized user. A privilege alters a user's access to database objects based on the database operations the authorized user may perform on the database objects. For example, a user may have a privilege that allows the user to read all data in a table but a privilege that does not allow the user to write data to the table. Database operations include data manipulation operations and database definition operations. Data manipulation operations include adding a row, deleting a row, and modifying contents of a row, among others. Database definition operations include adding a table, adding a column to a table, and adding an index for a table, among others. Other database operations include logging on to the database system and establishing a communication session with a database server.
Unfortunately, access controls employed by early commercial database systems did not conveniently satisfy information access control requirements established by some organizations.
For example, a user granted access to the database had access to all tables in the database. This did not support many security policies, such as multi-level security policies. For example, information in a database of military units and their capabilities are subject to a multi-level security policy. The multiple levels include unclassified, confidential, secret, and top-secret. According to this policy, information classified as secret may only be accessed by users who are cleared through the secret level or higher. This data may be viewed by a user cleared through top-secret level but not an unclassified member of the general public or a user cleared through the confidential level. To provide the access control required by the multi-level system using some conventional access controls, data at each level would be kept in a separate database. Placing data in separate databases based on security level duplicates storage, increasing storage space requirements, and greatly decreases efficiency.
One approach to provide the access control required by the multi-level system is to store different level data in different tables of the same database. In some embodiments of this approach, the data tables are stored in separate files with access controlled by an operating system. Placing data in separate tables and files based on security level is still very inefficient.
To increase efficiency, in some database systems, information for several levels are included in a single database object and access controls are applied for each data item in the database object. For example, access controls are applied for each row in a table. The database server of the database system is modified in numerous places to enforce access control for a multi-level security policy at the granularity of individual rows.
A multi-level security policy, with data item granularity, implemented in some later database servers still has some deficiencies. One drawback is that only one security policy is allowed for the database system, yet one security policy does not meet the needs of all users. For example, the multi-level policy does not suit some commercial applications which would control access to corporate data based on a labels associated with the corporation's unique corporate hierarchy. As another example, the multi-level policy does not match file access controls of a UNIX operating system, which allow user, group and world access separately on reading and writing files. Some user may want to apply the corporate hierarchy labels, another user may want to apply the UNIX operating system labels, and a third user may want to apply a combination of both on the same data. Using conventional approaches, three different database servers would be developed to support the three combinations of the two label-based policies.
Another drawback is that any modification to the security policy is implemented as changes to instructions scattered throughout the set of instructions that provide the behavior for the database server. Managing multiple scattered changes of an instruction set is difficult, costly, prone to error, and can result in unanticipated and undesired side effects. For example, programmers responsible for modifying the code of the database server to implement a single change in a security policy may make modifications to seven distinct places in the source code, without realizing that modifications are also required at two other locations. By failing to make changes in all locations, the database server may fail to operate properly, and may even operate in a manner directly contrary to the policy change for which modifications were being made.
In addition, it is desirable for a security policy to be added to an existing database server without taking the database server offline, so that users of a database system are not prevented from continuing to perform database operations. When users find a database system is unavailable, those users often become dissatisfied with that database system, may feel that the database system is unreliable because it is offline, and may decide not to use that database system in future projects.
Based on the foregoing description, there is a need for applying several policies simultaneously to the same data item in the database.
In addition, there is a clear need for a database system that allows one or more access control security policies to be added to a common database server without rewriting the database server.
Furthermore, there is a clear need for a database server that can integrate a new security policy without taking the database server offline, e.g., without making the database server unavailable to users of the database system.